前幾篇一路寫 AI Product 的 Metrics,我慢慢發現一件事情:
數字不好看時,反而比較好判斷。
Accuracy 很低,至少知道 Quality 有問題。
Latency 很高,可以去找 Performance Bottleneck。
根本沒有人使用,也許是入口、需求或 Adoption 有問題。
真正讓我覺得難的,反而是另一種情況:
每一個數字分開看,好像都不錯,但我還是不確定這個 Product 到底做對了沒有。
假設今天有一個 AI Assistant,上線一段時間後 Dashboard 長這樣:
WAU +30%
Answer Accuracy 92%
Response Time 2.5 sec
Cost / Query -20%
Task Completion 55%
Human Escalation 35%
前四個數字看起來都滿漂亮的。
有人用。
回答也準。
速度可以接受。
成本甚至下降。
但如果 User 最後只有 55% 完成原本的 Task,而且超過三成最後還是需要人工接手,我就不太敢說:
這個 Feature 成功了。
這時候真正困難的問題不是:
哪個 Metric 最重要?
而是:
這些看起來互相矛盾的 Metric,到底在告訴我什麼?
以前做 Product,我很習慣先看:
PV
UV
CTR
CVR
Retention
AI Product 當然也還是需要 Adoption。
如果根本沒有人使用,後面再好的 Accuracy 都沒有意義。
但 Usage 高最多只能證明:
User 願意嘗試這個 Solution。
它還不能證明:
這個 Solution 真的把 Problem 解掉了。
尤其 AI Product 很容易出現一種假象:
User 問一次
↓
答案不夠
↓
再換一句問
↓
再 Regenerate
↓
繼續追問
從 Dashboard 看,Messages、Turns、Session 全部上升。
但 User 可能只是:
一直沒有得到他真正需要的結果。
所以我現在看到 Usage 高,第一個反應不再是:
Great,大家很愛用。
而是:
至少 Demand 存在。接下來呢?
第二個很容易誤判的是 Accuracy。
假設 Team 的 Eval 顯示:
Answer Accuracy = 92%
很不錯。
但 User 的 Task 可能不是:
得到一個正確答案。
而是:
理解規則
↓
找到自己的資料
↓
確認資格
↓
完成申請
↓
得到結果
AI 可能在第一步回答得非常準,
但到了後面:
拿不到 Data
沒有 API
Permission 不足
需要切到另一個 System
最後還是找人工
那 Answer Accuracy 再高,都不代表 Product 完成了 User 的 Task。
這也是我現在越來越想把:
Model Quality
跟:
Product Outcome
分開看的原因。
一個 AI 可以是很好的 Model,
但還不是一個很好的 Product。
如果今天真的看到前面那組 Dashboard,我不會先問:
哪個數字最差?
我會先問:
User 原本到底想完成什麼?
假設原本的 Goal 是:
讓 User 可以 Self-service 完成某個資訊查詢或流程。
那我會先看:
Task Completion
如果只有 55%,代表真正的問題在這裡。
接下來我才往回拆。
先不要管 AI 說了多少話。
我會先確認:
Task Completion
Time to Completion
Abandonment
Human Escalation
如果 Outcome 本身很好,
才值得往 Cost / Efficiency 優化。
如果 Outcome 根本不好,
現在去省 Token,可能不是最重要的問題。
如果 Task Completion 低,
下一題才是:
是 Model / Answer Quality 的問題嗎?
例如:
Wrong Answer
Wrong Retrieval
Wrong Interpretation
Missing Context
Hallucination
如果 Quality 本身就不好,
那可能要處理:
Prompt
Context
RAG
Model
Eval Dataset
但如果 Accuracy 已經 92%,
Task Completion 還是只有 55%,我就會開始懷疑:
真正的 Bottleneck 可能根本不在 Model。
接著我會去看 Journey。
可能 User 已經得到正確答案,
但下一步還是要:
切 System
重新登入
再填一次資料
不知道去哪裡按
不知道 AI 已經做到哪裡
這些都不是 Accuracy 能告訴我的。
所以我會開始看:
Drop-off Step
Turns per Task
Retry
Rephrase
Manual Handoff
有時候 AI 本身答對了,
真正失敗的是整條 Product Journey。
這是我覺得 AI Product 很值得看的另一個數字:
Human Escalation
但 Escalation 高也不能直接說不好。
因為我要先知道:
為什麼需要人工?
可能是:
Model 不知道
→ Quality Problem
Data 拿不到
→ Integration Problem
沒有 Permission
→ Authorization Problem
沒有 Tool
→ Capability Problem
Business Rule 必須人工決策
→ 正常 Boundary
這五種原因完全不一樣。
所以真正值得量的不是:
35% Escalation,好高。
而是:
這 35% 到底是哪些 Failure Mode?
分類之後,Product Decision 才開始變清楚。
最後才是:
Latency
Token
Infra Cost
Human Cost
不是說 Cost 不重要。
而是我現在會把它放在:
成功完成一個 Task,需要付出多少成本?
而不是:
一次 Model Call 多便宜?
這兩個問題差很多。
如果今天看到一個 Dashboard,我大概會照這個順序 Review:
1. OUTCOME
User 最後完成 Task 了嗎?
↓
2. QUALITY
如果沒完成,是 AI 結果不好嗎?
↓
3. FRICTION
還是 Journey 某一步把 User 卡住?
↓
4. INTERVENTION
人工為什麼需要進來?
↓
5. COST
成功完成一次 Task,花多少資源?
↓
6. DECISION
下一輪真正應該改哪裡?
最後那一格其實最重要。
因為不同 Diagnosis,下一步完全不同:
Outcome ↓ + Quality ↓
→ 改 Model / Prompt / Context / Data
Outcome ↓ + Quality ↑
→ 查 Journey / Integration / Tool
Outcome ↑ + Intervention ↑
→ Review Automation Boundary
Outcome ↑ + Cost ↑
→ Optimize Efficiency
Usage ↑ + Outcome ↓
→ 不要被漂亮 Adoption 騙了
這時候 Dashboard 才不是一堆數字,
而是真的開始幫 PM 做 Decision。
以前我很容易問:
AI Product 最重要的 Metric 是什麼?
Accuracy?
Task Completion?
Cost?
Escalation?
寫到現在,我反而覺得這個問題本身可能就不太對。
因為一個 Metric 只能告訴我:
某一層發生了什麼。
真正的 Product Diagnosis 是把它們連起來:
Adoption
↓
Quality
↓
Journey
↓
Intervention
↓
Outcome
↓
Cost
然後找出:
到底哪一層,現在限制了 User 把事情做完?
AI Product 的 Metric 不是拿來證明 Feature 很成功,而是拿來找出:現在真正限制 Task Success 的 Bottleneck 在哪裡。
所以如果有一天我看到:
Usage 很高
Accuracy 很高
Latency 很低
我大概還是會多問一句:
很好,那 User 最後把事情做好了嗎?